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This document defines a number of message fields beyond those 
discussed in RFC 561. The overall message format is compatible with 
RFC 561; it makes extensive use of the miscellaneous fileds defined 
within RFC 561. The purpose of this document is to establish ARPANET 
standards with regard to the syntax and semantics for these 
additional fields. It is fully expected that all fields discussed 
herein will not be automatically processed by all Message Servers; 
however, the standard is necessary so that sites which wish to make 
use of these fields have a standard to work with. 


This document attempts to tread the narrow line between features for 
human processing and features for machine processing. The general 
feeling is that the fields listed are useful to people even if 
automatic processing is not supplied. In most cases, machine- 
readable notations have been enclosed in angle brackets (<>) to allow 
easy non-ambiguous ways for automatic processes to know whether and 
where to look in any field. The entire specifications has been made 
excessively general to allow for experimentation. Future documents 
based on experience will try to be more specific. This is simply the 
next step following <RFC 561>. 


This document is contained in two sections. Section I contains the 
relevant parts of RFC 561 which define the basic message syntax. 
Section II lists the new (and existing) header fields together with 
their proposed uses. 
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SECTION I: 


RFC 680 


<message> 
<header> 
<required header> 
<date item> 


<date> 
<vdate> 
<tdate> 
<dayofmonth> 
<vmonth> 


<tmonth> 
<vyear> 
<tyear> 
<zone> 


<time> 
<sender item 


<optional header> 
<subjects> 


<subject item> 
<optional items> 


<optional item> 
<addressee item> 
<addressee keywork> 


<messid> 


<other item> 
<other keyword> 


<address list> 


<addressee> 
<mailbox> 

<host spec> 
<attention spec> 


BASIC MESSAGE SYNTAX 


<header><crlf><body> 


<required header><optional header> 


<date item><sender i 


tem> 


DATE: <sp><date><sp>AT<sp> 


<time>-<zone><crlf> 
<vdate> ! <tdate> 


<dayofmonth><SP><vmonth><SP><vyear> 


<tmonth>/<dayofmonth 


>/<tyear> 


one or two decimal digits 


JAN ! 
JUL ! 


FEB ! 
AUG ! 


MAR ! AP 
SEP ! OC 


one or two decimal digits 


four decimal digits 
two decimal digits 
EST ! EDT ! CST ! CD 
PST ! PDT ! GMT ! GD 
four decimal digits 
SENDER: 
<crlf> 
<subjects><optional 
'<subject item> ! 
<subject item><subje 
SUBJECT: <sp><line><c 
<optional item> ! 
<optional items> 
<messid> ! <addresse 
<other item> 


R ! MAY ! JUN ! 
T ! NOV ! DEC 
T ! MST ! MDT ! 
T 


items> 


cts> 
rlf> 


e item> ! 


<sp><user><sp>AT<sp><host> 


<optional item> 


<addressee keyword>:<sp><addressee 


list><crlf> 

TOs CEs I- -BES Ss! 
Message-ID:<sp>[<Net 
Address>}]<line> 
<crlf> 


<other keyword>:<sp><line><crlf> 


FROM ! IN-REPLY-TO! 
KEYWORD ! PRECEDENCE 
MESSAGE-CLASS! 
SPECIAL-—HANDLING! 
ACCESSION-KEY 
<addressee> ! 
list> 


<mailbox> ! <mailbox 


REFERENCES! 
! 


group> 


AUTHENTICATION! 


<addressee><addressee 


<user><host spec><attention spec> 


!@<host> 
(ATTN:<sp><user list 


>) 
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<user list> 
<mailbox group> 
<group numbers> 
<mailbox list> 
<body> 

<user> 

<host> 

<group name> 
<line> 


<word> 


<CRLF> 


<SP> 


Notes: 


<user> ! <user><user list> 

<group name>: (<group numbers>) 

! (<mailbox list>) 

<mailbox> ! <mailbox>,<mailboxlist> 
<line><CRLF> ! <line><CRLF><body> 
<word> 

a standard host name 

! <word> 

a string containing any of the 128 
ASCII 

characters except CR and LF 

a string containing any of the 128 
ASCII 

characters except CR, LF, and SP 
CR LF 

space 


1. A message may have at most one MESSAGE-ID item. 


2. All items with the same keyword must be grasped together. 


Please note the following: 


(1) The case 


' DATE’, ' SUBJECT’, 
is insignificant. 


ERTA, 


(upper or lower) of keywords -- specifically, ‘FROM’, 
<host>, <zone>, <vmonth> and <keyword> -- 
Although ’FROM’, for example, appears in 


upper-case in the formal syntax above, in the header of an actual 
message it may appear as /’/FROM’, ’from’, or '’From’, etc. 


(2) No attempt has been made to legislate the format of <user> 
except to exclude spaces from it. 


(3) The time has no internal punctuation. 
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SECTION II: MESSAGE HEADER FIELDS 


A. ORIGINATOR SPECIFICATION FIELDS 
FROM 


This field contains the identity of the person who wished this 
message to be sent. This is expected to be the originator field 
which is specified by the user in the case that the message is being 
entered by one person for another. The message-creation process 
should default this field to be the user entering the message. [The 
usage for FROM and SENDER differs from that of RFC 561.] 


SENDER 


This field contains the identity of the person who sends the message. 
This field is expected to be set by the message-creation process 
automatically. It is possible that some sites will not include this 
field in external communications. 


AUTHENTICATION 


This field contains a description of which originator fields have 
been authenticated, and by which operating systems. This field 
should be created by message transmission and/or reception processes 
(FTP/Operating System level). 


It is expected that current system will be able to authenticate only 
the SENDER field; however, later systems might have mechanisms to 
verify that the FROM actually authorized the SENDER to act on his/her 
behalf. It is expected that, when the FROM is authenticated, the 
SENDER will no longer be necessary for external distribution. 


B. REFERENCE SPECIFICATION FIELDS 
MESSAGE-ID 
This field contains a unique identifier to refer to this message. 


The format for a message identifier is: 


[Net Address]Text String CRLF 
Examples: 
[ISIB] 7-DEC-74.14:23:45 
[ARC] QLOURNAL 39274a3 
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The uniqueness of the message identifier is guaranteed by each net- 
address message processor making the text which follows unique for 
that net-address. This, specifically says net-address and not site 
name. This would allow BBN (for instance) to allocate unique 
identifiers over all four machines, which may be addressed as BBN 
within the message system, thus producing a more integrated service 
for their users. 


The text following the net-address is not defined here, as the 
problems associated with this specification are too great at this 
time. However, the net-address should allow automatic processes to 
determine if they can deal intelligently with the following text. 
Several types of automatic processing by the local message reader are 
thus possible: 1) if the site uses a filing mechanism known to the 
reader, the reader can retrieve the message 2) if the site supports 
remote message access (protocol not currently defined), the message 
id can be passed to the remote site and the message has been filed in 
the Datacomputer (using the entire message id [including net-address] 
as the handle), the reader can retrieve it from the Datacomputer. 


IN-REPLY-TO 


The contents of this field identify previous correspondence which 
this message answers. If message identifiers are used in this field, 
they should be enclosed in angle brackets (<>). 


REFERENCES 

The contents of this field identify other correspondence which this 
message references. If message identifiers are used, they should be 
enclosed in angle brackets (<>). 


KEYWORDS 


This field contains keywords or phrases from the message, separated 
by commas. 
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C. RECEIVER SPECIFICATION FIELDS 
TO 


This field contains the identity of the primary receivers of the 
message. 


CC 


This field contains the identity of the secondary receivers of the 
message. 


BCC 
This field contains the identity of the tertiary receivers of the 
message. This field should not be made available to the primary and 


secondary receivers, but it may be recorded to provide information 
for access control. 


D. MESSAGE-TYPE SPECIFICATION FIELDS 


PRECEDENCE 


This field describes the importance and urgency of the message. 
Machine-readable notations will be enclosed in angle brackets (<>). 
<PRIORITY> means that the message should be delivered as soons as 
possible. <ROUTINE> means that Priority processing is not necessary. 
Plain text may also be included in this field. 


MESSAGE-CLASS 

This field describes the "legal" status of the message. Examples: 

Official, Unofficial, Record, Off the Record, Junk Mail. No 

automatic processing of this field is immediately expected. Certain 

message creation processes might, for example, always insert: 
MESSAGE CLASS: Unofficial ARPANET Message 

SPECIAL-HANDLING 


This field contains any special instructions with regard to the 
handling of the message at the receiver's end. Machine-readable 


notations will be enclosed in angle brackets (<>). <PRIVATE> means 
that the message reception process should not aid the user in 
circulating copies to others. Plain text may also be included in 
this field. 
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